wo 2004/010330 PCT/IB2003/003216 



10/52188? 

DT01Rec'dPCT/r- 19 JAN 2085 



DATABASES SYNCHRONIZATION 



Field of the Invention 

The present invention relates generally to communications systems and, 
5 in particular, to techniques that provide for synchronizing databases. 
Synchronization Is the act of establishing equivalence between two data 
collections, where each data item in one collection maps to a data item in the 
other one, and each item and its respective mapping having a content, which is 
the same, or equivalent or which corresponds to predefined requirements. 

10 this invention particularly applies to removable devices, such as a SIM 

(Subscriber Identity Module) smartcard, that can be inserted into different 
terminals. 

In the context of the invention, a database has to be understood as a data 
container (e.g. table, file...). No presumptions about its structure are needed. 

IS In the same manner, an item is a specific datia of a database, (e.g. a 

record of a file, a row of a table,...) 

Prior Art 

Synchronization protocols are used to synchronize the content of a 
20 database owned by a firist s^tem, generally a client, with the content of another 
database owned by a second system, which Is generally a server. Both systems 
can be connected and can exchange messages (synchronization niessages) 
tiislng different transfer/session protocols (e.g. HTTP (HyperTexl Transfer 
Protocol), WSP (Wireless Session Protocol),...). 

25 The synchronization principles are basically the following: 

- Firistly, client and server systems arrange some initial 
synchronization parameters ( e.g. which databases are going to be 
synchronized, type of synchronization...); 
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- Secondly, one of them (the first system) sends the changes 
(additions, modifications,... ) which have occurred since the last time their 
databases were synchronized between themselves. These changes are 
often stored in a file called ChangeLog file. This ChangeLog file reflects all 

5 the modifications in particular the identity of the database record for which 

the event occurred and a timestamp indicating when the event took place. 

- Then, the second system processes the ChangeLog received 
(modifying its database if required), and sends its own changLog to the 
first system. 

10 - Following the ChangeLog received, the first system changes its 

database if required. 

- Then, both systems exchange acknowledges and other finalization 
messages if required, ending the synchronization process. 

In the above process, the first system could be a mobile phone and the 
15 second system a personal assistant. Modifications may also occur in the SIM 
card coupled to the mobile phone. In this case, all the modifications, which occur 
in the SIM, are stored in the ChangeLog file included in the first system. 
Nevertheless, two important facts must be considered when trying to define a 
snnartcard synchronization solution: 

. 20 - The smartcard is a removable device that can be inserted into different 
systems; 

- This content of the smartcard can be accessed and modified by different 
systems using different transport mode (by APDU (Application Protocol 
Data Unit) cohimands from the terminal, by Over The Air (OTA) 

25 commands, etc.). 

These two facts have a clear initial consequence: 

- For synchronization purposes, the smartcard cannot be managed as a 
simple memory accessed by one system, because its memory is not 
attached or controlled by a unique system. 
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- Moreover, due to the lack of resources (memory, processing or 
communication capabilities), the smartcard is not able to support a 
complete synchronization protocol. In particular, contrary to systems such 
as mobile phone or personal assistant, a smartcard has no clock for dating 
5 a modification of its content. 

The Invention 

The main purpose of the invention is to provide a smartcard which 
manages its own modifications, ensuring a synchronization between a database 
10 stored in the smartcard itself instead of using a copy or the corresponding 
ChangeLog stored in the mobile phone as in the prior art. 

According to the invention, for databases synchronization purpose, a 
program external to the removable device sends a command to the removable 
device for setting a synchronization object to said first database, a 
IS synchronization object being affected to said first database, said synchronization 
objiect being also affected to the second database once the synchronization step 
between the two databases has been successfully performed, said object 
defining the last database synchronization which has been performed between 
said two databases. 

20 In this way, a synchronization object is linked to a database in ttie smart 

card, and this synchronization object is set by an extemal program stored in a 
system outside the smartcard, this system having the necessary resources for 
performing a database synchronization. So that, with the invention, the smartcard 
can be inserted In any device, ensuring a synchronization of its databases, 

25 independently of the system which has modified its content. 

It will be easier to understand the invention on reading the description 
below, given as an example and referring to the attached drawings. 
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In the drawings: 

Figure 1 is a schematic view a system in which the invention csm be 
applied. 

Figure 2 is an algorithm illustrating the different steps of a practical 
5 example. 



Detailed description of a practical example 

Figure 1 Is a schematic view of a system. SYS including a SIM card CAR 
coupled to a mobile phone MOB. In our example, this system SYS also includes 
10 a digital assistant (PDA) communicating with the mobile by way of a network IFR. 
Tfiis networl< could be for example an infrared connection. 

In our example, the card CAR stores a database DB1 and the assistant 
stores a database DB2. In another example, the second database could be 
stored in the smartcard CAR itself. 

15 . In our example, the mobile MOB, for example under user request, wants 

to synchronize the database DB1 with the assistant database DB2 both 
connected by the infrared port. 

In our example, each database DB1 and DB2 is a file of the same nature. 
More particularly, the database DB1 to be synchronized is the user's phonebook 
20 contained in a file EF (Elementary File) of the user's card CAR. 

Generally, the Mobile equipment MOB is able to interrogate the smartcard 
using APDU messages over the standard T=0 protocol. We will refer to this 
standard for niore explanations about this protocol. 

According to the invention, the smartcard supports synchronization object 
25 managing and modification detection. In our example, the mobile phone MOB 
having access to the smartcard has three commands to get and exploit the 
information related to synchronization objects and modification detection. 
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Synchronization objects will be linked to a database and represent a 
specific state of the database after a successful synchronization with a specific 
device. 

In our example, there are three new commands fictitiously named 
5 NewSync, GetChanges, StoreSync, The functions of theses commands are 
explained below: 

NewSync: With this command, the mobile MOB informs to the smartcard 
that a new synchronization of the data of one of its database DB1 with a second 
database (DB2) has to be perfonmed. The smartcard answers with the identifier 
10 of the synchronization object affected to the database DB1, if exists, defining the 
last time that this database DB1 has been synchronized with the database DB2 
(synchronization object is referred as "last synchronization objecf ). Preferably, It 
also proposes a new synchronization object defining the state of the database 
after this current synchronization ("new synchronization objecf). 

15 GetChanges: With this command, the mobile MOB asks for the 

modifications of the database DB1 which has occurred since the last 
synchronization object. The smartcard CARD answers with the identifiers of the 
database items modified, added or deleted. Preferably, only the identifiers are 
returned. So, if required, the mobile MOB could make use of its local copy of the 

20 smartcard memory to follow with the synchronization protocol. 

StoreSync: With this command, the mobile MOB infomis to the smartcard 
CAR that the synchronization has been performed. (Changes may have occurred 
in the smartcard following the synchronization protocol managed by the device). 

The smartcard CAR will replace the last synchronization object by the new 
23 one, and will be henceforth able to detect further modifications in the database 
bB1. 

With these three conimands, the smartcard CAR will provide a set of 
actions required to perform a synchronization of data stored in the smartcard, 
considering the problems and restrictions defined before. 
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The different steps (steps 1 to step 4) illustrating the invention will give a 
better understanding of the invention. 

Stepi 

Before starting the synchronization protocol, the nnobile MOB sends to the 
5 smartcard CAR the NewSync command with the identifier of the PDA and the 
name or identifier of the file DB1 to be synchronized. The smartcard remembers 
that a previous synchronization with the same PDA has been performed some 
times ago, with a synchronization object named "04012002131412". In our 
example, the card sends back the last synchronization object identifier and 
10 proposes a new synchronization object identifier "0502200213141 2". 

Step2 

At this time, the mobile MOB starts a synchronization process with the 
assistant using_ one of the available synchronization protocols. The mobile MOB 
is able to initiate data synchronization with the PDA by the corresponding 
15 exchange of Initialization messages. 

The last synchronization object provided by the smartcard CAR can be 
used in the synchronization protocol to be compared with the last synchronization 
object stored in the PDA: 

- If synchronization objects do not match (or any of them does not exist), a 
20 full synchronization is requested by the synchronization protocol. It means that 
both devices muist exchange all the data (of the ADN file). In this case no usage 
of modification register is needed. All the database content is supposed to have 
been modified (added). In this case, the mobile sends a command [SLB3]to the 
card (CAR) for setting a synchronization object to said first database (DB1), said 
25 synchronization object being also affected to the second database (DB2) which 
content has been synchronized with database (DB1). Then, in this case, the 
synchronization process is finished. The setting step is a configuration step In 
which the generation of a synchronization object is requested. 
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- If the two last synchronization objects match, it means that a successful 
synchronization was perfonned in the past, and that both devices may exchange 
only modifications occun-ed since this last synchronization. In this case, the 
following step is Step 3. 

5 Step 3 

The mobile equipment may interrogate the smartcard to know about the 
changes occurred since the moment when the last object was set It sends a 
GetChangea command, and the smartcard answers with the list of the 
modifications (e.g. "Added record 1 and 2, modified record 4, deleted record 7% 
10 The mobile equipment MOB may then perfomn following commands to know 
what has been the result of the modifications. For instance, it can read the record 
4 to see its value (maybe not if It has it in a local copy). 

In this step, the mobile MOB and the assistant exchange their 
modifications following the used synchronization protocol. 

15 Once it has all data need it can continue the synchronization protocol 

sending the following messages with the client modifications and eventually 
. receiving and performing the server modifications. 

Stfep 4 

Once th^ synchronization protocol is finished, the mobile MOB shall send 
20 a StoreSync command to the smartcard, to set the new synchronizatloh object. 
Once this command Is performed, the smartcard will be able to detect changes 
henceforward performed. 

The smartcard stores the active synchronization object as the last 
synchronization object for future synchronization with the same PDA. Hereafter, 
25 the smartcard will be able to detect changes performed after this moment 
following commands in future synchronization. 

Some additional comments can be added to this example: 

- If we insert the smartcard Into another mobile MOB and we try to 
synchronize again with the same PDA, synchronization can be performed 
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because change detection and synchronization objects management are 
independent from the. system in which is inserted the smartcard. 

- Advantageously, synchronization of both devices can be performed in 
any protocol supported by them because, the 3 commands included in the 

5 synchronization procedure preferably does not force any specific requirement to 
the synchronization protocol. 

- Any other device having access to the smartcard and to the three new 
synchronization commands as illustrated in our example can substitute the 
mobile. ( e.g. OTA server); 

10 - The methods defined can also be used to synchronize smartcard data 

With the local copy of the smartcard data in the mobile equipment. This is a local 
synchronization between the smartcard and the mobile equipment. 

Generally, the invention provides some interesting features. 

In our Illustrated invention, we have seen that, for databases 
15 synchronization purpose, an external program reads the synchronization object 
iri the removable device and compares it with the synchronization object affected 
to the second database, compares them, and function of this result, synchronizes 
data in the databases. The extemal program can be located in the mobile phone 
or In another system communicating with this mobile phone. So that, when a 
20 synchronization process has to be performed in the future between a first and a 
second databases (DB1,DB2), the synchronization object is used because 
defining the last database synchronization which has been performed between 
said two databases (DB1 ,DB2), 

We have also seen that, for initiating a synchronization step, the first 
25 system (MOB) Informs to the removable device CAR that a new synchronization 
of the data of one of its databases with another system (PDA) is to be performed, 
then the removable device CAR answers with the current synchronization object, 
if exists, defines the last time that this database has been synchronized with this 
systiem PDA, and also proposes a new synchronization object, for future use, 
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defining the state of the database after the current synchronization. The old and 
the new synchronization object can be sent in a same message or in two 
different messages. 

We have also seen that when the fjrst device MOB asks for the 
S modifications of the database, which have occurred since the last 
synchronization object, the removable device answers with the identifiers of the 
database items modified, added or deleted. Preferably, only the identifiers of the 
database Items are returned, the device MOB being able to make use of its local 
copy of the removable device CAR memory to obtain the database content and 
10 to follow with the data synchronization process. 

We have also seen that the device MOB preferably infomis to the 
removable device MOB that the synchronization has been performed. The 
removable device replaces the last synchronization object by the new one, this 
new synchronization object being able to detect further modifications since the 
15 last synchronization. 

Preferably, the mobile MOB sends, for information, a command to the 
removable device with the identifier of the device and the name of the database 
to be synchronized. 

The invention also deals with a removable device, in particular a smart 
20 card CAR. After each synchronization step of said database DB1 with said 
second database DB2, the smart card receives a command initiated by an 
external device requesting to set a synchronization object to said first database 
DB1, said synchronization object being also affected to an outside second 
database (DB2) which content has been synchronized with database DB1 . 

25 The invention also deals with a system MOB able to communicate with a 

removable device CAR. This system comprises a program for sending, when 
synchronization between the two databases (DB1,DB2) has been performed, a 
command to said removable device CAR for setting a new synchronization 
object, said new synchronization object being also affected to the second 

30 database DB2 which content has been synchronized with database DB1. 
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-We see now that the invention offers many advantages. The invention 
provides a method to manage its modifications and interfaces to access to these 
methods whatever the entity accessing to the smartcard is. In easier words, the 
smartcard perfomns some required actions to be integrated in the synchronization 
S process. So that, the smartcard is able to support a complete synchronization 
protocol. 



